This invention relates in general to computer user interfaces and, more specifically, to user interfaces for selecting information.
The explosion of information availability is well documented. With so much information available, and at a low cost, the real value an entity seeking information receives is in being able to filter large amounts of information to bring to the forefront specific bits of information of interest to the entity. For example, a user of a hypertext browsing system might find portions of web pages from a number of different web sites. The user may want to aggregate the portions of web paged from the different web sites into a single web page such that browsing the separate sites is not necessary. In another example, the user may find a database of all major movies made, but is interested in only a small number of movies. The user would not be interested in being notified of all movies being made, but only of those movies being made that are of interest to that user.
The most ubiquitous hypertext system available today is the Internet, a global internetwork of networks, that supports various packet communication protocols, such as TCP/IP (Transport Control Protocol/Internet Protocol) that carry higher level protocols, such as HTTP (HyperText Transport Protocol) to transmit HTML (HyperText Markup Language) documents between an HTTP server and an HTTP client, as well as handling other HTTP client-server communications tasks. In a common operation, an HTTP client presents a user with an HTML page containing hypertext links to other HTML pages and the user might select one of the links and be presented with a second HTML page that is referenced by the hypertext link. Such links are referred to as “Uniform Resource Locators” or “URLs”, and the act of displaying and clicking links is often referred to as “browsing”. Consequently, an interactive HTTP client that displays hypertext pages and retrieves pages using URLs is often referred to as a “browser”.
The links between interrelated hypertext pages form a web and the set of interrelated hypertext pages hosted on Internet servers is typically referred to as the “World Wide Web”, “WWW” or just “the Web”. Consequently, a browser that is used to browse the Web is often referred to has a “Web browser”. Herein, “Web site” refers to a collection of hypertext pages, typically assembled and controlled by one entity or a set of related entities. A “Web server” is a server that responds to requests from a Web browser or compatible client. Requests to a Web server are often in the form of HTTP requests, but might include other types of requests.
A portal operator might set up an HTTP server or HTTP server farm (the “portal server”) to serve requests from clients seeking information provided by the portal operators. The HTTP server is often referred to as the portal operator's “website” because a browser (or other HTTP client) appears to “go” to a new location in the Web when the URL for the portal operator's HTTP server is specified. Thus, the act referred to as “going to a website” does not involve any movement per se, other than a change of focus of the HTTP client and a display of the HTML code representing that website.
The portal operator might maintain a set of preferences at the portal server for each user that has set up an account with the portal operator. Thus, if the portal provider allows the user to select or deselect categories of information, such as stock quotes, news and weather, a user that is not interested in the weather could set preferences to indicate that when that user requests a portal page from the portal server and the portal server has identified the user, the portal server should serve an HTML page that contains current stock quotes and news, but not weather. Since the page served by the portal server is customized to the user when the portal server has identified the user, the page served is often referred to as that user's portal page.
Portal servers allow for user customization based on preferences, but the typical portal operator only allows a user to build the user's portal page from components (“snippets”) made available by that portal operator. Furthermore, the data used to populate the snippets is typically limited to the data (“content”) the portal operator makes available. For example, a user might set up the user's portal page to show the weather in San Francisco and Dallas and the news related to baseball, if the portal operator provided a weather snippet and a sports news snippet. The values for the weather data and the news items presented in those snippets are the values and items provided by that portal operator.
Because each portal operator has snippets and content that is specific to that portal operator, many users maintain several portal pages at several portal websites. Thus, a single user might have dozens of customized portal pages on dozens of different portal websites, even though the user is only interested in selected content from each of those portal websites.
While most portal operators are aggressively expanding their repository of snippets, the user is still limited only to those snippets that were pre-designed by the portal operator. An example of this is shown in FIG. 1, which is a screen capture illustrating a typical process of snippet selection for a portal page. As shown there, pre-designed content is organized into topic groups shown on the left of the display. In that display, the “News” topic is highlighted and a list of news snippets is listed to the right of the display. The user can check (or uncheck) snippets to be included (or excluded) from the user's portal page, but the user is generally limited to the list of snippets provided by the portal operator.
Some portal operators use streams of information in a data format known as “XML data streams” (eXtensible Markup Language), often provided by vendors whose product is a supply of information in XML data stream form. Even with XML data streams, the user's portal page will be limited to the streams and content that the one portal operator has pre-designed for portal pages. Furthermore, the typical user either cannot turn an XML data stream into presentable form, such as an HTML page, or does not want to bother with the effort. More often, the XML data streams are fed to the computing infrastructure of the portal operator and from there are converted into presentable HTML format and made available as snippets to users of that portal operator's service.
In an example of one use of a Web browser, a user might “navigate” the browser to a particular Web page, by providing the Web browser a URL referencing that particular Web page. In some cases, the Web page is static, in that it exists before it is requested and a Web server responds to a request for that static page by just returning a copy of that static page. In other cases, the Web page is dynamic, in that it is created in response to the request and the Web server returns a copy of the dynamic page to the requestor after the page is created or as the page is created. The process of dynamic page creation might depend on the data contained in the URL and/or information the Web server has about the requestor.
Using a Web browser, a user might navigate to a Web site dedicated to movies and check what new movies have come out. To keep up to date, the user would visit the site regularly, checking for new movies, but this requires effort and scheduling, if the user is to keep up to date with developments in more than a few areas.
Some Web site operators have addressed this situation by setting up their servers to notify, often by email, users when some event occurs. For example, one popular Web site sends the user an email when a DVD the user had expressed interest in has been released. Other Web sites might notify the user as a message in their customized portal page for that user. This approach does not address the problem of multiple information sources: the user either has to go to multiple Web sites to look for these alerts or sift through the user's email inbox for them. In the case of email alerts, the user is likely to be added to mailing lists only to be bombarded with marketing information the user does not want to get.
Moreover, the web site operator's ability to check for a condition is limited to the content it (the web site) provides. For example, a DVD commerce site operator cannot alert the user as a stock quote goes up or down such that separate email alerts are needed from the DVD and stock sites. The user notification is also limited to a set of pre-designed conditions. That same DVD commerce site operator might not be able to alert the user in the specific event that a new movie by a certain director has been released, unless that site is set up with those pre-designed conditions. Instead, the user has to select from a pre-designed set of alerts and receive email alerts from many different sites.
As mentioned above, many Web sites already offer notification mechanisms. These notifications are usually based on and related to the Web site's own content. FIG. 2 shows an example from a Web site for an online retailer. A user wanting to buy a certain movie would visit the site and look up the desired movie. If the site responds that the title is unavailable or not yet released, the site then offers the user a chance to sign up for a notification service, where the user gives an email address to which the notification is sent. The Web site server would then add the user's email address to a database and the server includes programs that will notify users when events occur, such as the availability of the desired movie for purchase.
FIG. 3 shows another example from an investment site. The site lets the user set complex alerts based the user's portfolio. The user is again limited to a pre-designed, albeit customizable and quite extensive, set of conditions for a specific field of interest, which in this case is stock quotes. The user is not able to aggregate alerts from multiple sites in one place.